This is G o o g l e's cache of http://www.rockbox.org/twiki/bin/view/Main/EncoderDiscussionMP3 as retrieved on 8 Sep 2005 03:22:32 GMT.
G o o g l e's cache is the snapshot that we took of the page as we crawled the web.
The page may have changed since that time. Click here for the current page without highlighting.
This cached page may reference images which are no longer available. Click here for the cached text only.
To link to or bookmark this page, use the following url: http://www.google.com/search?q=cache:ZhcaWQmLneQJ:www.rockbox.org/twiki/bin/view/Main/EncoderDiscussionMP3+site:rockbox.org+twiki+encoderdiscussionmp3&hl=en&client=firefox


Google is neither affiliated with the authors of this page nor responsible for its content.
These search terms have been highlighted: encoderdiscussionmp3 
These terms only appear in links pointing to this page: twiki

Rockbox . Main . EncoderDiscussionMP3

 Rockbox Logo 

home
download
documentation
mailing lists
wiki
IRC
forums
daily builds
feature requests
bug reports
patches


SourceForge.net Logo

Rockbox > Main > EncoderDiscussionMP3
Main . { Users | Changes | Index | Search | Register | Go }

MP3 Encoder Discussion

(Please refrain from flames here. Add facts. I tried to clear up previous arguments to make this page less "personal" / DanielStenberg)

There aren't very many free/open real-time MP3 encoders around.

Shine

We could use the Shine encoder by Gabriel Bouvigne, but it is very basic and needs quite a lot of work to achieve good quality. Any takers?

I've downloaded the source code, modified it so it compiles on my machine, implemented some intial hacks to get the ball rolling, but no gaurantee on the outcome. The sound quality is not the greatest, will require a lot effort to get a good encoder. Maybe 192kbps files will sound good -- DerickHugunin

I've found a fixed-point and optimized version of the Shine MP3 encoder for ARM and StrongARM, which should be portable to Coldfire. On a closer look, there are some double's left (initialization routines etc). Description Source

Use iriver's

Could the existing encoder be extracted from iriver firmware and made a plugin for rockbox? Would this violate rockbox's license (GPL)?

Could rockbox call the existing code in the iriver firmware? The code is already there in ROM, it would be like Linux making PC BIOS calls.

You are already hacking the firmware to add a bootloader. This would be just hacking it a bit more :)

Post Recording Encoder

A non-realtime encoder would be acceptable for now. Eg capture .wav and then compress to .mp3 in a batch process later. This can apply to all codecs for which there is no realtime encoder available yet, eg OGG/Vorbis. Why compress inside the player instead of doing it later on a desktop PC or laptop? Well, not everyone wants to lug a PC or laptop out in the field when capturing audio. Compressing it inside the player with rockbox would be very convenient and the quality could potentially be much higher than a realtime encoder because you don't have to cut corners.

We still have the problem that there is no quality integer lossy encoder other than WavPack? lossy (which is already being ported by the developer). Vorbis, Lame and etc. all depend on an FPU. While we could probably emulate an FPU on the ColdFire, speed would be so overwhelmingly slow that you would probably run out of battery before the first track was encoded.

(No need to point out fixed-point libs here, the actual encoder code would be to be adjusted to use fixed-point and it could be done any way you want, using a fixed-point lib or not.)

Q: Would it be possible to use a bridge codec which uses directly the inbuilt hardware encoder for iRiver?

A: The iRiver encoder is not hardware based. It's a software decoder, probably this one. So no, we cannot use that.

This encoder provided by freescale would probably be a clever solution, but that would require that Freescale is willing to allow the RockBox project to use it with reasonable license conditions. That is not likely.

Reasons Against MP3 Encoding

Fraunhofer Hostility

Given the incredible hostility of Fraunhofer and the tons of patent encumbrances around mp3. I don't see why we should reward fraunhofer's misbehavior with promoting their patent-encumbered format, when they'll just turn around and stab you in the back. Can you even legally bundle an mp3 encoder? The patents would seem to point to "no". IMO vorbis is far more worthy of effort (it's a better codec anyway).

Fraunhofer stopped being hostile towards MP3 encoders distributed for free years ago. These days, they only go after people making profit out of MP3 encoding and not paying the licensing fees.

Because they succeeded in shutting most of them down? :) lame avoided the c&d by distributing purely as patches against dist10. i dont know how gogo avoided it. the rest (bladeenc, 8hz, etc) promptly capitulated on receipt of the c&d letters.

Patents

Q: Can you even legally bundle an mp3 encoder? The patents would seem to point to "no".

A: MP3 decoders suffer from pretty much the same patents. If we go that way, we'd have to strip off mp3 decoding as well.

It is best to steer clear of patents, especially when you absolutely know you are infringing. There is nothing better to fuel the anti-opensource argument of "they dont care about infringing on IP" if they can point to actual examples, and I would hate to see rockbox be that example. Surely there are other codecs (if not vorbis then MPC, FLAC, WavPack? or such) which could be integerized and dont infringe patents.

More info on patent licensing http://www.mp3licensing.com/royalty/index.html

Patent Fees Already Paid?

If Archos and Iriver paid their liscenses, isnt that good enough for us? (notable exception being the sims)

You mean a patent license is transferable from one product to another? Eg the license for mp3 is transferable from Microsoft Windows 2000 to Linux? Or are you implying the Iriver patent license for mp3 as a 'hardware device' covers anything which might run on the IHP? The latter interpretation would seem more reasonable. If that interpretation legally works then it would clear rockbox.

I guess if Iriver already paid "per unit" price of licensing, then there should be no problem using mp3 feature in rockbox since the use of it is paid. No matter who paid, isn't it?

I think we should ask here directly a guy from http://www.mp3licensing.com - so we get a correct answer. ChristianGmeiner 04.08.05

It is interesting to note that iriver is not listed as a licensee.

I don't think that tells us much. It could instead be the producer of the encoder (some software company) that's listed. JonasHaeggqvist - 25 Aug 2005

It would seem to confirm iriver is not the one paying the patent license fee, and that they just purchased software from a third party.

Either way, I don't know how we could rely on a license fee paid either by iriver or a third-party software company unless we could get a copy of the license agreement to review. -- MichaelDiFebbo - 26 Aug 2005

I'm personally of the opinion, that if it's good enough for debian-legal, it's good enough for everyone. JonasHaeggqvist - 26 Aug 2005

And if we get a "cease and desist" letter, we can allways do just that, remove the codec. :P -- MarkHawthorne - 26 Aug 2005

MP3 Decoding

If iriver and archos' license can be legally cover the hardware then rockbox may be in the clear. A lawyer would have to look at that though. If the iriver license cant legally cover the decoder, then yes it would be best to scrap the decoder even though that would suck. Doing otherwise could be viewed as unethical.

If we had to drop the mp3 decoder, we could as well scrap the whole project, because an MP3 player which doesn't play MP3... well... sucks.

{ Edit | View raw | Attach | Ref-By | Printable | Diffs | r1.34 | > | r1.33 | > | r1.32 | More }
Revision r1.34 - 26 Aug 2005 - 23:17 GMT - MarkHawthorne Copyright © 1999-2005 by the contributing authors.